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Abstract 

Aviation related applications that rely upon 
datalink for information exchange are increasingly 
being developed and deployed. The increase in the 
quantity of applications and associated data 
communications will expose problems and issues to 
resolve. NASA’s Glenn Research Center has 
prepared to study the communications issues that will 
arise as datalink applications are employed within the 
National Airspace System (NAS) by developing an 
aviation communications emulation testbed. 

The Testbed is evolving and currently provides 
the hardware and software needed to study the 
communications impact of Air Traffic Control (ATC) 
and surveillance applications in a densely populated 
environment. The communications load associated 
with up to 1 60 aircraft: transmitting and receiving 
ATC and surveillance data can be generated in real- 
time in a sequence similar to what would occur in the 
NAS. The ATC applications that can be studied are 
the Aeronautical Telecommunications Network’s 
(ATN) Context Management (CM) and Controller 
Pilot Data Link Communications (CPDLC). The 
Surveillance applications are Automatic Dependent 
Surveillance - Broadcast (ADS-B) and Traffic 
Information Services - Broadcast (TIS-B). 

Introduction 

NASA’s Glenn Research Center (GRC) has 
been performing Communications, Navigation and 
Surveillance (CNS) research under an element of the 
Airspace Systems Program. GRC’s activities have 
resulted in new tools for studying CNS technologies. 

A new project under the NASA Exploratory 
Technologies for the National Airspace System 
Program (NExTNAS) is planned to further enhance 


GRC’s activities on the research and development of 
CNS technologies. This project is known as 
Advanced CNS Architectures and System 
Technologies (ACAST). The project has been 
established to enable the transfer of network-based 
digital information. This capability is essential to 
facilitate the effective functioning of the new airspace 
management systems being developed for the long 
term. Hence, a research and development effort for a 
future CNS infrastructure, in parallel with the 
airspace system management research, is needed. 
ACAST fills this need. 

The impact that data link traffic loads will 
impose on the underlying communications 
infrastructure within the NAS is not well known. To 
better understand this impact, GRC is developing (in 
stages) an emulation and test facility to study data 
link interactions and the capacity of the NAS 
infrastructure to support the data communications 
requirements of various applications. The Virtual 
Aircraft and Controller (VAC) Testbed provides a 
means of observing the operation of large-scale 
aeronautical data link communications using different 
subnetworks. 

Communications Testbed Concept 

GRC’s capability to study the effects of 
communications on the NAS has been evolving. A 
study of the NAS’s digital communications 
requirements for 2015 w r as conducted in 1998. The 
project was referred to as Task Order 24. The TO 24 
study pointed out that a good communications model 
of the NAS did not exist and one should be 
developed. 

Modeling the NAS with all its complexities was 
beyond the scope that NASA wanted to undertake. It 
was decided to look at a smaller area that could 
represent the worst-case traffic loading. NASA 
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looked at the LA Basin in the year 2020 with the 
expected equipages. 

GRC undertook an engineering study effort to 
develop the Global Aviation Communications Test 
and System Emulation Facility (GACTSEF). NASA 
decided that GACTSEF should incorporate every 
communications system that will be fielded in the 


NAS. Since funding was limited, it was decided to 
build the facility envisioned in the GACSTEF study 
incrementally. 

The concept that resulted from the GACSTEF 
study has been refined into the VAC Testbed shown 
in Figure 1. 


Virtual Aircraft Environment 
(Up to 160 A/C) 



Laboratory Facility 


Figure 1. GRC’s Aviation Communications Emulation Testbed 


Evolutionary Development 

The GACTSEF implementation started with the 
first phase of the Virtual Aircraft and Controller 
(VAC) Testbed. It provided the capability for a single 
Air Traffic Control (ATC) controller to exchange 
Controller Pilot Data Link Communications 
(CPDLC) messages with five aircraft in real time. A 
“pilot” would enter a CPDLC message on a 
simulated aircraft display and send it via a 
communications network to the controller. 


The second phase added a scripting capability 
that permitted large-scale emulation of the 
communications exchanges. As many as 1 60 scripted 
aircraft can exchange CPDLC messages with 
multiple virtual controllers. 

The third phase added a VHP Digital Link 
(VDL) Mode 2 subnetwork to the VAC Testbed. 
VDL Mode 2 is the communications subnetwork that 
is supporting the FAA’s CPDLC Build I operations 
in the Miami ARTCC. 






The fourth phase is underway. It will add 
Automatic Dependant Surveillance - Broadcast 
(ADS-B) and Traffic Information Service -Broadcast 
(TIS-B) capabilities to the Testbed during the first 
part of 2004. 

The future phases involve true emulations of the 
radio frequency environment. This will allow 
Doppler shift correction, delay, and angle of arrival 
and reception variations due to antenna placement 
and patterns. 

ATN Emulation 

Aeronautical Telecommunications Network 

The Aeronautical Telecommunications Network 
(ATN) comprises application entities and 
communication services which allow ground, air- 
ground and avionics data subnetworks to inter operate 
by adopting common interface services and protocols 
based on the International Organization for 
Standardization (ISO) Open Systems Interconnection 
(OSI) reference model. The ATN is a worldwide data 
communications network for the aviation industry. It 
integrates a broad array of telecommunications 
systems and services used around the world. The 
ATN uses many existing telecommunications links 
and services, creating an “Aeronautical Global 
Internet” to distribute information between aircraft 
and ground stations supporting air traffic control, 
flight and airport operations, flight information 
sendees, maintenance communications, and even 
passenger services. 

Improvements in aviation system capacity and 
safety will require significant advances in the sharing 
of data among a host of different data nodes, systems, 
and networks, including all aspects of the aviation 
system, both airborne and ground-based. Data 
sharing requirements over the ATN wdll expand 
greatly and continuously into the future. 

A 77V Application Descriptions 

The ATN applications that are emulated in the 
VAC Testbed are Context Management (CM) and 
Controller Pilot Data Link Communications 


(CPDLC). 1 2 CM provides a logon service allowing 
initial aircraft introduction into the ATN and a 
directoiy of all other data link applications on the 
aircraft. It also includes functionality to forward 
addresses between Air Traffic Service (ATS) units. 

CPDLC is an ATN application that provides a 
means of ATC data communication between 
controlling, receiving or downstream ATS units and 
the aircraft, using air-ground and ground-ground 
subnetworks. The CPDLC data messages use 
phraseology that is consistent with the International 
Civil Aviation Organization (ICAO) phraseology for 
current ATC voice communications. 

VAC Testbed -ATN Components 

The first and second phases of the Testbed’s 
evolution are focused on implementing the ATN 
applications of CM and CPDLC. The Testbed ATN 
components are composed of software applications 
(the Applications) developed by Computer Networks 
& Software, Inc. that interface with routers using the 
Connectionless Network Protocol (CLNP), which is 
the ATN network layer protocol. The routers, in turn, 
are connected to aircraft and ground-based data link 
radios. 

The Applications provide a virtual aircraft / 
controller capability that emulates pilot / controller 
data link exchanges from as many as 160 aircraft 
using script-driven events. The Applications generate 
CM and CPDLC messages that are ATN compliant, 
the protocol standard that has been implemented by 
the FAA in the CPDLC Build I system. The CPDLC 
message set includes all the messages in Aeronautical 
Data Link Service (ADLS) Baseline I, which is the 
set of messages that was to be implemented in the 
FAA’s CPDLC Build IA program. 

The Testbed also includes workstations with 
aircraft and controller graphical user interfaces at 
which users can generate and respond to CM and 
CPDLC messages. The ATN components of the 
Testbed’s architecture are shown in Figure 2. 

The VAC Testbed software provides script- 
driven (referred to as autonomous) and human- 
interactive message emulation. End-to-end emulation 
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Figure 2. CM and CPDLC Communications Architecture 


is provided through script-driven, departure- 
through-arrival scenarios that support a full range of 
communications test activities. It is complimented 
by a human -interactive capability where users can 
enter messages using controller and aircraft 
displays. 

The System Manager application provides 
configuration control, scenario and script selection, 
experiment management, and data reduction and 
analysis capabilities. 

Autonomous Aircraft 

From 1 to 160 Autonomous Aircraft (AA) can 
be included in an experiment. The autonomous 
aircraft reside on workstations (personal 
computers), with multiple aircraft assigned to each 
workstation. The workstation receives its 
configuration from the System Manager and 
launches each aircraft at the appropriate time. The 


application builds and transmits the CM and 
CPDLC messages at the scripted time. It also 
responds to messages received from the controller. 
Transmitted and received CM and CPDLC 
messages are encoded/decoded, time-stamped, and 
stored for later reduction. 

Autonomous Controller 

The autonomous controller provides the 
System’s Air Traffic Management portion of the 
test and experiment capability. It initiates and 
responds to scripted air-ground CPDLC events as 
the System’s Air Traffic Controller. The controller 
workstation receives its configuration from the 
System Manager. The configuration data includes a 
script for each aircraft that will communicate with 
the controller. The controller application builds and 
transmits CM and CPDLC messages to each aircraft 
at the scripted time. It also responds to CM and 




















CPDLC messages received from aircraft. 
Transmitted and received CM and CPDLC 
messages are encoded/decoded, time-stamped, and 
stored locally for later reduction. 

Human-Interactive Aircraft 

The human-interactive aircraft application is 
resident on one of the workstations and provides a 
graphical user interface that emulates a generic 
Master Communications Display Unit (MCDU) 
(Figure 3). The MCDU facilitates “human in the 
loop” pilot test participation. The application builds 
and transmits CM and CPDLC messages in 
response to user inputs via the MCDU. Each 
message is stored locally with an appropriate time- 
stamp. Received CM and CPDLC messages are 
decoded and displayed on the MCDU as well as 
time-stamped and stored. If a received message 
requires a response, the user is presented with a list 
of responses appropriate for that particular message 
from which to choose. 


is stored locally with an appropriate time-stamp. 
Received CM and CPDLC messages are decoded 
and displayed as well as time-stamped and stored 
locally. If a received message requires a response, 
the user is presented with appropriate responses 
from which to choose. 



Figure 4. Controller Display 



Figure 3. Aircraft Display 


Human-Interactive Controller 

The human-interactive controller application 
provides a graphical user interface that emulates a 
generic ATC workstation display for both the CM 
and CPDLC applications (Figure 4). As its name 
suggests, the controller display facilitates “human 
in the loop” testing. The application builds and 
transmits CM and CPDLC messages in response to 
user inputs via the controller display. Each message 


System Manager 

The System Manager provides the means to 
develop a library of scripts and experiments. The 
user develops a script by entering the time and 
CPDLC declarative and request messages that are 
to originate from the aircraft and controller. The 
user prepares an experiment configuration by 
assigning aircraft and controllers to workstations 
plus assigning scripts and starting times to aircraft. 
Each aircraft and controller is assigned an unique 
address that conforms to the ATN standards. 

When the user starts an experiment, the 
System Manager distributes the aircraft and 
controller configurations to the assigned 
workstations. The System Manager displays the 
progress of each aircraft in the execution of its 
assigned script. Performance statistics are collected 
by the aircraft and controller applications during the 
experiment and transmitted for display at the 
System Manager. 

Once the experiment has been completed, all 
of the data collected by each aircraft and controller 
is sent to the System Manager for storage and report 
generation. Numerous data reports can be prepared 
to analyze the performance of the System during the 
experiment. 




Performance Measurement 

The Testbed provides a means to measure the 
end-to-end delay associated with using ATN 
applications over various subnetworks. “End-to- 
end” delay in this context starts when an ATC 
controller sends a message and the pilot receives it. 
Or, it starts when the pilot sends a message and the 
controller receives it. The applications are CM and 
CPDLC. The air-ground subnetwork that is 
supporting CPDLC Build I is based on the VDL 
Mode 2 protocol. 

The Testbed can provide an insight into the 
number of data link equipped aircraft that can 
operate safely on a single frequency. The FAA’s 
transfer delay requirements for CPDLC are shown 
in Table 1 2 , while the mean delay budget for the 
CPDLC Build LA system is shown in Figure 5. 3 The 
mean delay requirement in the en route domain is 
1 0 seconds, while the budget used in developing the 
CPDLC IA system is 8.6 seconds (mean). The 
budget component allocated to air-ground 
communications is three (3) seconds. 

GRC can perform experiments using the 
Testbed to estimate the number of aircraft that can 
operate on a single frequency while satisfying the 
delay requirements. The Testbed can generate the 
data link messages associated with up to 160 
separate aircraft flying realistic flight profiles. The 
user via a scripting mechanism defines the flight 
profiles. The results of the experiments can be 
compared to the FAA’s delay requirements. 


Table 1. CPDLC Transfer Delay Requirements 


Domain 

Mean 

End-to-End 
Transfer Delay 

95% 

End-to-End 
Transfer Delay 

99.996% 
End -to-End 
Transfer Delay 

Terminal 

5 sec 

8 sec 

12.5 sec 

En Route 

10 sec 

15 sec 

22 sec 


2 Initial Requirements Document for Controller Pilot Data Link 

Communications (CPDLCl Service . Federal Aviation 

Administration, June 22, 1998 

2 Draft FAA Specification for Controller Pilot Data Link 
Communications Build-IA (CPDLC-IAt . Federal Aviation 
Administration, January 5, 2000 



Figure 5. Mean Transfer Delay Time Budgets 

VDL Mode 2 Communications Equipment 

The next evolutionary step in developing the 
VAC Testbed was the addition of a VHF Digital 
Link (VDL) Mode 2 communications capability. A 
SITA VDL Mode 2 ground station was 
incorporated into the Testbed along with four 
aircraft radios and software emulations of a 
Communications Management Unit (CMU). Figure 
6 shows the interfaces between the original Testbed 
equipment and the SITA VDL Mode 2 
communications equipment. 

Surveillance Applications 

ADS-B 

The addition of Automatic Dependent 
Surveillance - Broadcast (ADS-B) to the Testbed 
provides the capability to study a new surveillance 
technique that will be implemented in the NAS. An 
ADS-B aircraft broadcasts information about itself 
on a periodic basis. The period can be as short as 
once per second. The information includes the 
aircraft’s address, identification, location, speed, 
and equipage. The VAC Testbed implementation 4 
includes the Mode Status Report and State Vector 
messages as defined in the RTCA ADS-B 
Minimum Aviation System Performance Standards 
(MASPS). 5 


4 System Specification to NASA GRC for the Virtual Aircraft 
and Controller - Build C . Version 2.0, Computer Networks & 
Software, Inc., July 8, 2003 

5 DO-242A, Minimum Aviation System Performance Standards 
for Automatic Dependent Surveillance Broadcast fADS-Bl . 
RTCA, June 25, 2002. 
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Figure 6. VDL Mode 2 Communications Equipment 


When an ADS-B aircraft transmits a Mode 
Status Report or a State Vector message, similarly 
equipped aircraft receive information about the 
aircraft. The receiving aircraft can use the State 
Vector message to display the aircraft's location on 
a Cockpit Display of Traffic Information (CDTI). 
As a result, the receiving aircraft can “see” the 
sending aircraft’s location in relation to its own, 
even when the climate does not let the pilot see it 
visually. 

Air Traffic Control (ATC) systems can also 
receive the ADS-B messages and use the data to 
supplement the surveillance data acquired from 
radars. 


TIS-B 

The Testbed’s Traffic Information Service - 
Broadcast (TIS-B) capability can be used to study a 
new surveillance capability that will be 
implemented in the NAS in the next few years. In 
contrast to ADS-B’ s aircraft-to-aircraft 
transmissions, TIS-B ’s aircraft location data is 
broadcast from the ground by the ATC system. 

Aircraft data available to the ATC system 
comes from ground-based surveillance radars and 
ADS-B reports. The data from multiple reports is 
correlated and the best surveillance data available is 
broadcast to all aircraft in the area. 








As an approach to control costs and reduce the 
quantity of equipment on an aircraft, TIS-B 
messages are transmitted on the same frequency as 
ADS-B. In addition, the avionics that receives 
ADS-B messages should be able to process TIS-B 
messages. 

Each TIS-B message is a report about a single 
aircraft. The message is referred to as a Target 
Report. A message will include the target’s 
identification, location, and speed. The report will 
also include an indication as to the accuracy of the 
location data. The VAC Testbed implements the 
Target Report format defined in the RTCA TIS-B 
Minimum Aviation System Performance Standards 
(MASPS), DO-286. 

ADS-B & TIS-B Communications 
Architecture 

The communications architecture for the ADS- 
B implementation is shown in Figure 7. The 


architecture includes Autonomous and Human 
Interactive Aircraft (AA and HIA), Autonomous 
and Human Interactive Controllers (AC and HIC), 
and a System Manager. The protocols for 
exchanging ADS-B and TIS-B messages over the 
Testbed Local Area Networks (LANs) are Ethernet 
(IEEE 802.3), Internet Protocol (IP) and User 
Datagram Protocol (UDP). 

The routers are connected to communications 
systems for transmitting the ADS-B and TIS-B 
messages. Figure 7 shows satellites being used as 
the communications medium. 

As mentioned earlier, the VAC Testbed can 
emulate the communications associated with up to 
160 autonomous aircraft. Each of those aircraft will 
be reported in a TIS-B Target Report. A subset of 
the 160 aircraft can emulate the broadcast of ADS- 
B messages. The experimenter can designate up to 
40 aircraft as having an ADS-B capability. 



Figure 7. ADS-B & TIS-B Communications Architecture 














Radio Frequency Environment 

The impact of different modulation schemes, 
antenna equipage, and adjacent radio channel 
interference effects upon data link communications 
is a concern of NASA. 

The U.S. Military is also concerned about the 
effects of the radio environment for war fighting. 
As a result, the United States Air Force and Navy 
Avionics Test Commands have developed the Joint 
Communication Simulator (JCS) to provide for the 
simulation of large-scale emitter environments. 

With the future need to emulate an active RF 
environment, the VAC Testbed may be modified to 
include the principles and capabilities that are 


available in the Joint Communications Simulator. 
(Figure 8) 

This system supports different wave forms, 
frequencies and power levels plus provides for 
communications delays. With this improved 
capabilities the Testbed should be able to model any 
proposed communications system and determine 
system capabilities before building prototypes. This 
can increase the efficiency and safety of future 
systems. 

This enhancement will also be able to model 
the interactions between voice and data circuits. 

This will assist in the proper placement of 
transmitters and channel selection for the aviation 
radio frequency environment. 
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Figure 8. VAC Testbed with Joint Communications Simulator 



Summary 

GRC’s VAC Testbed provides the capability to 
study the impact of data link traffic loads from 
various applications on the NAS communications 
infrastructure. The Testbed is evolving and provides 
a means of generating and observing the performance 
of large-scale aeronautical data link communications 
using different subnetworks. 

End-to-end ATN message (CM and CPDLC) 
emulation is provided through script-driven, 
departure -through-arrival scenarios that can support a 
full range of communications test activities. The 
capability to use up to 160 aircraft in an experiment 
couple with the Testbed’s performance measurements 
provides the means to assess the number of aircraft 
that a subnetwork can support and meet the FAA’s 
performance goals. The addition of VDL Mode 2 
subnetwork communications systems adds another 
dimension of realism to the analysis toolset. 

The implementation shortly of an ADS-B and 
TIS-B message emulation capability will support 
studies on new surveillance applications being added 
to the NAS. 

With the addition of the capabilities of the JCS 
this test facilities will be able to emulate any 
communication system that may be deployed. The 
performance will be quantified and deficiencies will 
be identified so that they may be mitigated upon 
deployment. 
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